Resolve file descriptors once per syscall - #1302

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

Static review findings (5-min budget, dual-model review: GPT-5.6 Sol + Opus 5)

Reviewed the actual diff vs origin/main (litebox_shim_linux/src/lib.rs, syscalls/file.rs, syscalls/mm.rs, syscalls/net.rs).

🟡 Medium — mm.rs ELF-patch path re-resolves the raw fd instead of reusing the pre-resolved handle

Location: litebox_shim_linux/src/syscalls/mm.rs:136 and :147 (feeding into init_elf_patch_state at :548, :581)

do_mmap_file resolves the descriptor once (let typed_fd = self.typed_fd(fd)… at line 121) and correctly threads &typed_fd into try_cow_mmap_file/do_mmap_file_memcpy. However, the ELF-rewriting path is still handed the raw i32 fd:

• maybe_patch_exec_segment(result, len, fd, …) (:136) → init_elf_patch_state(fd, …) (:768)
• init_elf_patch_state(fd, …) (:147, direct call)

init_elf_patch_state then re-resolves the raw fd twice more via self.sys_read(fd, &mut ehdr_buf, Some(0)) (:548) and self.sys_read(fd, &mut phdrs_buf, Some(e_phoff)) (:581), each doing a fresh raw_descriptor_store lookup.

Since the fd table is shared across CLONE_FILES threads, a sibling thread can close/dup2 over fd between the initial resolution (:121) and these later reads. Two concrete failure modes within a single mmap call:

1. sys_read returns EBADF → init_elf_patch_state silently skips patch-state init → maybe_patch_exec_segment treats it as "no patch needed" and reports the mapping successful but unpatched. For a pre-patched binary that requires the trampoline rewrite, this leads to a SIGSEGV on the first rewritten syscall instead of the intended fail path.
2. The slot was replaced by another file → ELF header/phdrs are read from a different file than the one actually mapped, and elf_patch_cache (keyed by the raw i32) gets populated with segment offsets from the wrong file.

This doesn't appear to be a regression introduced by this PR, but the PR's stated invariant ("resolve each raw fd once per syscall") isn't fully established for mmap's ELF-patch path even though a resolved AnyTypedFd is already in scope — it reads as an incomplete migration.

Suggested fix: Change maybe_patch_exec_segment and init_elf_patch_state to take &AnyTypedFd<Platform> (keep the raw i32 only as the elf_patch_cache key) and replace the two self.sys_read(fd, …) calls with self.do_read(typed_fd, …), matching what's already done for do_mmap_file_memcpy.

Confidence: High — independently identified by both reviewers (GPT-5.6 Sol and Opus 5) reviewing this file/chunk separately.

Verified clean (no action needed)

The rest of the diff (file.rs, net.rs, and the resolver logic in lib.rs) came back clean from both independent reviewers, with matching verified invariants:

• Every converted syscall resolves its fd exactly once per entry point (no re-resolution across chunked read/write, iovec, or *mmsg loops).
• Dispatch ordering and error-code precedence (EBADF/ENOTSOCK before EINVAL/EFAULT) match the removed run_on_raw_fd/with_socket code paths.
• No new use-after-free/refcount hazards: a concurrent close on a resolved Arc<TypedFd> fails closed (EBADF) rather than causing UAF or fd-confusion.
• No new lock re-entrancy or deadlock risk from holding self.files.borrow() across nested resolutions.